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Description 

BACKGROUND OF THE INVENTION 

[0001] The present invention relates to multicasting 
in data communicatlort networking and. more particu- 
larly, to mullicasting In a local area network (LAN) 
bridge. 

[0002] Traditionally, a LAN was a single broadcast 
domain shared among network devtees needing to 
communicate with one another. As more and more net- 
wotk devices were added to such LANs, competition for 
the shared bandwidth Intensified and communication 
began to slow. To overcome this protslem, devk:es called 
bridges were interposed to segment the network 
devices Into multiple broadcast domains. Traditional 
LANs then began to be called "LAN segments" within a 
larger network topology which Included multiple LAN 
segments, brieves, and often times a router for linking 
the network devices on the LAN segments with a back- 
bone network. 

[0003] Bridges are Intelligent devices which trans- 
mit packets from one broadcast domain to another over 
a shared backplane. Rather than transmitting packets 
indiscriminately, however, network interfeices on a 
bridge apply Media Access Control (MAC) bridging 
rules. Each network interface learns the MAC 
addresses of the network devices connected to the 
bridge through itself from the source MAC addresses 
encoded packets received from such devices. When a 
subsequent packet is received pn the backplane, the 
network interfaces are then able to individually check 
the packet's destination MAC address and determine if 
such address is among the list of previously teamed 
MAO addresses. If the address is lound In the list, the 
internee fonwards the packet. If it is not found in the list, 
the Interface filters the packet, unless no other interface 
on the bridge has claimed the packet. Through such 
"look up" operations conducted at each network inter- 
fiace. bridges advantageously reserve backplane and 
media bandwidth for packets requiring transmission in 
order to reach their Intended destination. 
[0004] Recent vintage bridges often Implement 
bridging rules in custom integrated circuits. Such 
bridges are commonly rafened to as "Switches", though 
their core functton Is not very different from traditional 
bridges. But by reducing basic bridging "look up" opera- 
tions to custom logic switches are aide to pass traffic at 
or near wire speed. Switches thus have reduced packet 
loss and latency as compared with more iHQcessor- 
dependent bridges. 

[0005] While bridged networks have advantages in 
speed and simplicity of implementation, they have expe- 
rienced problems handling multicast traffic. Multicast 
packets are not destined for any one network device, so 
the destination MAC addresses encoded in such pack- 
ets do not conBspond to a "source learned" address on 
any one network Interlace. Absent addlttonal rules, all 



network interfeces within the same subnetwoik will 
therefore capture and indiscriminately retransmit multi- 
cast packets. Incident to such pad<et "flooding", how- 
ever, is consumption of bandwidth on media where no 
s destination network device resides. In a multi-bridge 
environment, a spanning ^ee algorithm must also be 
run to prevent loops, imposing an additional tax on per- 
formance. 

[0006] One alternative to flooding multicast packets 

10 is conventional multicast routing. Multicast routing 
restricts multicast traffic to particular subnetworks and 
therefore reduces flooding. Accordingly, while speed 
and simplicity of implementatkm generally points toward 
bridging, multicasting requirements suggest a contin- 

15 ued place in a bridged network for routing. Out of this 
dichotomy were born bridges supporting tioth bridging 
and multicast routing. In a typical arrangement, a multi- 
cast router is configuFed on a processing entity logically 
interposed on a bridge backplane between network 

20 Hiteifeces. This "internal" router learns the multicast 
groups to which each of the bridge's network Internees 
belongs. Network inteFfaces transmit multicast data 
packets to the router using a weli-known destination 
MAC address of the router interface. The router con- 

25 suits a linulttoast routing database and resolves the 
packet's multksast destination network address (I.e., 
multicast group address) to a set of networi< interfaces 
on the bridge supporting such address. The router then 
retransmits the packet on the backplane. The network 

30 interfaces then apply conventional MAC bridging rules 
to the transmitted packet through such "look up" oper- 
ations performed at the router and network Interibces, a 
bridge/router advantageously reserves media band- 
width for only those multicast packets destined for sub- 

35 networks to which network interfaces belongs. 

[0007] The bandwidth savings realized by imple- 
menting mulUcast routing on a bridge has come at a 
price, however. First, multicast routing has required an 
-.Jixtrastep.in the forwarding process. Whereas abridged 

40 pa^SfitZiS reviewed only at the networkjoierfecas, a 
packet routed by a multicast router is reviewed at the 
ngwiM-k interfaces an d a puter interface. T he added 
loullflsrst^Hs-not only time-consuming but reqiSires a 
second transmission across the backplane. Moieover, 

4S some LAN segment bandwidth is^still wasted because 
muttteast routers discriminate onlj^t the iriterface level. 
Eackete therefore continue to be flooded out ports asso- 
ciated with an interface which has a host belonging to 
the multicast group even where no network device 

so belonging to that multicast group is reachable through 
the port Accordingly, there is a need for a multicasting 
capability for a bridge which has superky soeed and 
bandwidth conservation characteristics. 



[0008] In one aspect, the present Invention 
improves multicast communication in a bridge through 
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the expedient of distributed muiticast Ibiwarding with 
sut>-interface granularity. A plurality of netwrork Inter- 
faces share a backplaneof a bridge. The network inter- 
fiaces each have a plurality of ports and retain a local 
multicast database which associates multicast groups 
active on the intertaoe with local ports active in such 
groups. Forwarding decisions on multicast data packets 
transmitted on the backplane are made by network 
Interfaces by referencing their local multk»st data- 
bases. Each network internee fbnwards mutticast data 
packets only on the local ports which belong to the mul- 
ticast group identified in 'the packet. 
[0009] In another aspect, configuration of ttie tocal 
multicast databases is assisted by a management inter- 
face which shares the backplane with the network inter- 
faces. The management interface retains a global 
muittoast database which associates multicast groups 
active on the bridge with ports active in such groups. 
The management interface updates the active port lists 
for multicast groups in the global midtteast database 
with group/port association changes learned from multi- 
cast control packets transmitted on the backplane. The 
management interfeice transmits forwarding updates to 
the network interliaces having ports belonging to such 
groups. 

[0010] In another aspect, a particular network inter- 
face is made responsible Ibr each multicast group for 
fbnwarding multicast control packets and unknown mul> 
ticast data packets to management intertace ibr learn- 
ing in order to reduce oversubscription of backplane 
bandwidth. 

[001 1] These and other objects of the invention can 
be better understood by reiierenoe to Vne following 
detailed description, taken in conjunction with the 
accompanying drawings wivch are briefly described 
below. Of course, the actual scope of the invention is 
defined by the appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[00123 

Figure 1 is a block diagram illustrating a physical 
network in which the present inventkin is 
operative; 

Figure 2 is a block diagram Illustrating a logical view 
of the netMori( according to Figure 1; 

Figure 3 is block diagram illustrating the manage- 
ment interbce according to Figure 1 in 
greater detail; 

Figure 4 is a block diagram illustrating a network 
interface according to Figure 1; 

Figures is a flow diagram describing muiticast 
packet processing undertaken at the net- 



work interfaces according to Figure 1; 

Figures is a flow diagram describing multicast 
packet processing undertaken at the man- 
5 agement interface according to Figure 1; 

and 

Figure 7 Is a flow diagram describing the global and 
local multicast database update process 
10 undertaken at the management and net- 

work interfeces according to Figure 1 . 

DETAIl^D DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

IS 

[0013] In Figure 1, a physical data communication 
network 100 in which the present invention is operative 
is shown. Network 100 includes hosts 110 on distinct 
broadcast domains interconnected with other hosts and 

20 with resources in backbone network 120, including 
router 122 and server 124, via bridge 130. Bridge may 
implement l>ridging rules and distributed multicast for- 
warding in custom integrated circuits, processors, or a 
combination. Hosts 110 are addressable network 

25 devices, such as PCs, workstations and servers. Brklge 
130 has a plurality of network interfaces 132 and a man- 
agement interiace 134 interconnected over backplane 
136. Backplane 136 is illustrated as a common bus, but 
may take other forms, such as a matrix of root-to-leaf 

30 connections or point-to-point connections between net> 
work interfaces 132. Backplane 136 may operate at half 
or full duplex. Management interface 134 and network 
interliaces 132 are linked by control lines 138. Hosts 110 
and backbone network 120 are interconnected to net- 

35 vrork interfaces 132 on physical ports 1-10. Network 
interfaces 132 may support various CSMA/CD or token- 
passing protocols operative on their associated broad- 
cast domains, such as Ethernet, Fast Ethernet, Gigabit 
Ethernet, Token Ring and Fiber Distributed Data Inter- 

40 face (FDDI). Naturally, if backbone network 120 is a 
connection-oriented network, such as an Asynchronous 
Transfer Mode (ATM) networi<, the network inteface 
associated with network 120 will support such connec- 
tion-oriented protocol. Where bridge 130 is operating In 

45 a multi-protocol environment, packets are encapsulated 
using a format commonly understood by interfeces 132, 
134 before transmission on backplane 136. 
[0014] Figive 2 presents a k^ical view 200 of phys- 
ical network 100. Multfcast communication between and 

so among hosts 110, and between hosts 110 and back- 
bone network 120, is conducted through virtual network 
interfaces 232 and virtual ports a-j. Each of .the physical 
network internes 132 may be associated with one or 
more of virtual network interfooes 232. and each virtual 

55 network interface may be associated with one or more 
of vHual ports a-j. Associations between physical net- 
work interi'aces 132 and virtual network interlaces 232, 
and between physical ports and virtual ports, may be 
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made either statically or dynamically. The basic multi- 
cast forwarding operation on bridge 130 is accom- 
plished by resolving on network interfaces 132 
identifiers in multicast data packets, Including multicast 
group addresses, to virtual ports or, if not available, vir- 
tual mterlaces, and forwarding such packets on the 
resolved virtual ports or virtual interfaces. The resolved 
multicast group addresses are encoded in the destina- 
tion network address field of multicast data packets. 
[001 5] Refen-ing to Figure 3, management interfiace 
134 is shown In greater detail. Management interface 
134 has multicast manager 310, group/port database 
312 and global mutticast database 314 fijr facilitating 
the distributed multicast forwarding operation. Multicast 
manager 310 learns associations from three different 
types of multicast packets transmitted on backplane 1 36 
and records them In databases 312 and 314. First, mul- 
ticast manager 310 learns multicast group to virtual port 
associations from host membership packets originated 
by hosts 110 and records them In group/port database 
312. Second, multicast manager 310 learns mulBcast 
group to virtual port associations from route control 
packets transmitted by neighboring routers, such as 
router 122, to midticast router 320 and records them in 
group/port database 312. Third, mutticast manager 310 
learns associations between source network 
addresses, multteast group addresses and ingress 
ports from unknown mulficast data packets originated 
by network devices, such as hosts 110, and records the 
associations as "master" entries in global database 314. 
The ingress port Is the virtual port on yvtjiph the multi- 
cast data packet arrived at bridge 130. Multicast man- 
ager 310 consults the group/port associations recorded 
in group/port database 312 and updates the virtual port 
element of "master" entries in global database 314 for 
the multicast group through an internal (to management 
interliace 134) data transfer operation. Contents from 
"master" entries are transferred firom management 
Interface 134 to network interfaces 132 belonging to the 
multicast group "out of band" on control lines 138 
through an external (to management interface 134) data 
transfer operation. Network interfaces 132 employ the 
transferred contents of "master" entries to construct and 
update "Shadow" entries allowing network Interfaces 
132 to make efficient fbnvarding decisions on multicast 
data pad<ets received from on backplane 136 from 
other network interfaces. Particularly, "shadow" entries 
are consulted by network interfaces to make forwarding 
decisions on multicast data packets without central 
processor Intervention on a packet-by-packet basis. 
Moreover, because tfie contents of "master" entries 
received from global database 314 inckide associations 
between multicast groups and virtual ports, the forward- 
ing decisions made by network internees 132 by con- 
sulting the "shadow" entries advantageously result in 
mufficast data packets being forwarded only on the set 
of virtual ports which belong to the target multicast 
group. 



[001 6] In a preferred embodiment, group/port data- 
base 312 is arranged such that each multicast group in 
database 312 has its own group table which includes a 
pointer to the flrst entry in a linked list of entries idenlify- 

5 ing virtual ports active in the group. A timer value is 
stored in association with each virtual port in the list 
such that stale ports age-out of the list. 
[0017] Multicast router 320 learns multicast group 
to virtual network interface associations from host mem- . 

10 bership packets and route control packets. 

[OOiq The first packet type relied on by multicast 
manager 310 to configure bridge 130 for distributed 
multicast fonwarding Is the host membership packet 
Host membership packets have a type identifier, which 

15 identifies such pac1<ets as host membersNp packets, 
and have a mutticast group address. By way of example, 
host membership packets nray include Internet Group 
Management Protocol (IGMP) Version IWo (v.2) Mem- 
bersNp Reports and Leave Group packets. For each 

20 mutticast ^oup active on bridge 130, a single networi( 
interlace is delegated responsibility for fonwardlng to 
management internee 134 host membership packets 
for a the group to avoid duplicate processing of host 
membership packets by multicast manager 310. Dele- 

2B gation is made such that the responsible network Inter- 
face is always associated wtth at least one port 
belonging to the multicast group for which the 'uiterface 
is responsible. 

[0019] The second packet type relied on by multi- 
30 cast manager 31 0 to configure bridge 1 30 for distributed 
multicast fonwarding Is the.route control packet, Route 
control packets are Originated by neighboring routers, 
such as router 122. Route control packets have a type 
kientifier, which identifies such packets as route control 
3S packets, and have a multicast group address. By way of 
example, route control packets may be Internet Group 
Management Protocol (IGMP) Version Two (v.2) Dis- 
tance Vector Multicast Routing Protocol (DVMRP) pack- 
ets. 

40 [0020] The third packet type relied upon by multi- 
cast manager 310 to configure bridge 1 30 for distributed 
multicast fonwarding is the unknown multicast data 
packet. Unknown mutticast data packets are originated 
by netwoilt devtees, such as hosts 110. Unknown mutti- 

45 cast dat4 packets are characterized by a combination of 
packet identifiers, including source network address, 
multicast group address and Ingress port, for which 
there Is no matching entry in the local multicast data- 
bass of any of network internees 132. F<>r each multi- 

so cast group active on bridge 130, a single network 
Interface Is delegated responsibility for forwarding 
unknown mutticast data packets to management inter- 
face 134 for the group to avoid duplicate processing of 
unknown multicast data packets by multicast manager 

55 310. Delegation Is made such that the responsible net- 
work interfece is always associated with at least one 
port bekmging to the muitteast group for whid) the inter- 
face Is responsible. Preferably, the same network inter- 



4 



7 



EP 1035 685 A2 



8 



face responsible for forwarding host membership 
packets for a particular multicast group is responsible 
for forwarding unknown multicast data packets for fliat 
group. 

[0021] Refening now to Figure 4, a representative 
network interface 432 is shown. Network interfeoe 432 
is representative of network interfaces 132 for purposes 
described herein. Network interfeice 432 has interface 
controller 410, claiming database 412, responsibility 
database 414 and local multicast database 416 for 
accomplishing distributed multicast fonwarding. Control- 
ler 410 is responsible for maintaining databases 412, 
414, 416 and for packet fonvarding. Controller 410 
learns multicast forwarding information from manage- 
ment interfoce 134 through two different types of mes- 
sages transmitted on control lines 138. The first type of 
message controller 410 receives Is a "forwarding 
update" message including contents of a "master" entry 
from global multicast database 314. Each 'fonvarding 
update" message includes a source network address, 
multicast group address, ingress port and virtual port, 
and may include other control information such as vir- 
tual local area network (VLAN) identifiers. For each "for- 
warding update' message received, controller 410 
constructs or updates up to three entries. First, contrd- 
ler constructs or updates in local multicast database 
416 a "shadow" entry which includes the source net- 
work address, multicast group address, ingress port 
and virtual port corresponding to the transferred con- 
tents of "master" entry. Second, controller 410 records 
in claiming database 412 th^ MAC address oon^spond- 
ing to the multicast group address identified in the trans- 
ferred contents of "master" entry, if such destination 
MAC address has not already been recorded. In this 
regard, MAC addresses are numerically related to mul- 
ticast group addresses In a preferred embodiment such 
that multicast group addresses for a distinct set of mul- 
ticast groups are resolvable to a MAC address. Third, 
controller 410 records In responsibility database 414 an 
entry callable by the MAC address oorrasponding to the 
multicast group address identified in the transferred 
contents of "master" entry, if such entry has not srfready 
been created. The second type of message controller 
410 receives is a "responsibility" message designating 
interface 432 as the responsible interface for a multicast 
group for which there is at least one "shadow" entry in 
local multicast database 416. Controller 410 sets a flag 
in responsibility database 414 in a reserved field in the 
entry callable by the MAC address corresponding to the 
multicast group for which interface 432 is delegated 
responsibility. In a preferred embodiment, claiming 
database 412 is implemented in a content addressable 
memory (CAM) and responsibility database 414 and 
local multicast database 416 are implemented in ran- 
dom access memory (RAM). Accordingly, the CAM 
index at which a MAC address resides in claiming data- 
base 412 may be advantageously recorded In responsi- 
bility database 414 in lieu of the complete MAC 



address. 

[0022] interoperability of network interfiaces 132 
and management interface 134 in distributed multicast 
forwarding may be even more clearly understood by ref- 

5 erence to Figures 5 and 6. Figure 5 illustrates the 
processing algorithm run by representative network 
interfaces 432 on a mulficast packet received from 
backplane 136. Upon arrival from backplane 136 at net- 
work interfeice 432, MAC database 412 Is consulted to 

10 determine whether the packet has a destination MAC 
address known on Intertace 432 (510). II the packet 
does not have a destination MAC address known on 
Interface 432, a check is made to determine whether 
another one of network interfeices 132 knows the destl- 

15 nation MAC address or management interface 134 has 
claimed the pad<et (512). In this regard, network Inter- 
faces 132 Indlvkiually "look up" the destination MAC 
address of packets transmitted on backplane 136 and 
share information about recognized addresses in a 

20 manner well known to the art, such as the assertion of 
"daim" line by any Interface which recognizes the 
address. If the destination MAC address has been 
claimed by one of network Interfaces 132 or manage- 
ment interface 134, the packet is dropped by interface 

2S 432 (550). If, however, the destination MAC address has 
not been claimed by any of network interiaces 132 or 
management Interface 134, the packet is an unknown 
multicast packet and is fkxided by Irrteiface 432 (and all 
other network interfaces 132) (552). Returning now to 

30 Step 510, if the packet has a destination MAC address 
known on Interface 432, the packet is a known multicast 
data packet. Thus, a check is made to see If the packet 
is a membership control packet (520). If the packet is 
membership control packet, responsibility database 414 

3S is consulted to determine If interiiace 432 is the respon- 
sible network interface for the multicast group Identified 
in the packet (530). if interface 432 is the responsible 
network interface, interface 432 must fonward the packet 
to multicast manager 310 for learning and recording of 

40 multicast group to virtual port associations In group/port 
database 312. Thus, in that event, the destination MAC 
address is replaced with a destination MAC address 
reserved for management Interface 134 and the packet 
is retransmitted on backplane 136 (556). If interface 432 

45 Is not the responsible network interface, however, 
another one of network Interfaces 132 Is responsible for 
forwarding the packet to multicast ntanager 310 and the 
packet is dropped by Intertace 432 (558). Returning to 
Step 520, If the packet Is not a membership control 

50 packet the packet Is a multicast data packet having a 
multicast group address for whidi there may be con-e- 
sponding entries in local multicast database 41 6. There- 
fore, local multicast database 416 is consulted for a 
matching entry (532). A match Is found if there is a 

£5 "shadow" entry in local multicast database 412 having a 
source network address, multicast group address and 
ingress port corresponding to those identified In perti- 
nent fields of the packet. If no matehing entry is found. 
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the packet is an unknown multicast data packet and a 
check is made to see if internee 432 is the responsible 
network interfiace Ibrthe multicast group (530). If inter- 
face 432 is the responsible network interface, interfeoe 
432 must forward the unknown multicast data packet to 
multicast manager 310 for teaming and recordiru) of a 
"master" entry in global multicast database 314. Thus, 
in that event, the destination MAC address is replaced 
with the destinatton MAC address reserved for the man- 
agement interface 134 and the packet is retransmitted 
on backplane 136 (556). If the network interface is not 
the responsible network interface, the packet Is dropped 
(538). Returning to Step 532, if a matdiing 'shadow" 
entry is found in local multicast database 416, the 
packet is a known multicast data packet and is for- 
warded on the set of virtual ports specified in the virtual 
port list for the matching entry (554). 
[0023] Figure 6 illustrates the processing algorithm 
riin by management interface 134 for processing multi- 
cast packets received from backplane 136. In accord- 
ance with Figure 6, upon arrival from backplane 136 at 
management interface 134, the destination MAC 
address is reviewed to determine if the packet has a 
destination MAC address reserved for interface 134 
(610). if the packet does not have a destination MAC 
address reserved for interface 134, a check is made to 
determine whether the packet has been claimed by one 
of network interfeices 132 (612). If the packet has been 
claimed, it is dropped by management interfaoe 134 
(614). If, however, the packet has not been claimed by 
one of netvwrk interfaces 1 32, the packet is an unknown 
multicast packet and must be processed further by 
management interface 134. Returning to Step 610, if 
the packet has a destination MAC address reserved for 
interface 134. or If the pactot is an unknown multicast 
packet, a check is made to determine if the packet is a 
multicast control packet (620). If the packet Is not a mul- 
ticast control packet, the packet is an unknown multicast 
data packet and is learned by recording a "master" entry 
In global multicast database 314 (622). If, however, the 
packet is a multicast control packet, the packet is 
reviewed to determine whether an update must be 
made to group/port database 312 (630). In this regard, 
the entry in group/port database 312 corresponding to 
the multicast group identified in the packet is "looked 
up" and determination is made whether the ingress port 
identified in the packet is among the ports in the virtual 
port list associated with the entry. Any necessary 
changes are made to the group/port database 312 {i.e., 
add port or delete port) (640) before fonwarding the 
packet to multicast router 320 for further processing 
(642). For example, if the ingress port klentified in a 
IGMP v.2 Host Membership Report is not already 
present in the entry, the ingress port is added to the vir- 
tual port list. If no change is required to group/port data- 
base 312, the packet is simply fonwarded to multicast 
router 320 (642) without any update being made. 
[0024] Figure 7 IHustrates the processing algorithm 
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run between management interface 134 and network 
interfaces 132 to update the virtual port lists in global 
multicast database 314 and to update local multicast 
databases. In accordance with the algorithm, multicast 

5 manager 310 compares the virtual port list in group/port 
database 312 for a particular multicast group with the 
wrtual port list in a "master" entry in global database 
314 for the same multicast group to see if there is any 
disparity (710). If there is no disparity (Le., there is a 

10 one-to-one correspondence between the virtual port 
lists), no further action is taken. If, however, there is a 
disparity, the "master" entry is updated by transferring 
virtual port information from group/port database 312 to 
global database 314 (720). In that event, multicast man- 

1S ager 310 transmits to a network interface associated 
with the virtual port for which the "master" entry was 
updated a "fonwarding update" message reflecting the 
change made to global multicast database 314, result- 
ing in construction or update of a "shadow" entry in the 

20 network interface's local multicast database (730). 
[0025] It will t>e appreciated by those of ordinary 
skill in ttie art that the invention can be embodied in 
other specific forms without departing from the spirit or 
essential diaracter hereof. The present invention is 

25 therefore In all respects considered Illustrative and not 
restrictive. 

[002^ The scope of the invention is defined by the 
appended claims, and all changes that come within the 
range of equivalents thereof are intended to be 
30. embraced therein. 

Claims 

1. A method for forwarding a multicast data packet on 
35 a data communication bridge of the kind having a 

plurality of network Interbces sharing a backplane, 
each network interfiace having a plurality of ports, 
the method comprising: 

40 transmitting the multicast data packet on the 

backplane, the multicast data packet Mentilying 
a multicast group; 

determir^ng at a networi< Inteifoce which ports, 
45 if any, on the network Interface belong to the 

multicast group; and 

fonwarding the multicast data packet from the 
network interface on the ports, if any, which 
so belong to the multicast group. 

2, A method for forwarding a multicast data packet on 
a data communication bridge of the kind having a 
plurality of network interiaces sharing a backplane, 

55 the method comprising: 

transmitting the multicast data packet on the 
backplane; 
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reviewing information in llie multicast data 
packet for a matching entry at a network inter- 
nee, the information including a multicast 
group; and 

forwarding the multicast data packet from the s 
networlc Interface if a matching entry Is found. 

3. The method according to daim 2, wherein the net- 
work interface has a plurality of ports and the multi- 
cast data packet is forwarded only on ports io 
Identified in the matching entry. 

4. The method according to claim 2, wherein the 
matching entry is retained in a database at the net- 
work interface. 1S 

$. The method according to claim 2. further compris- 
ing: filtering the multicast data packet at the net- 
work interface if a matching entry Is not found. 

20 

6. The method according to claim 2, wherein the Infor- 
mation includes a source address. 

7. The method according to claim 2, wherein the Infor- 
mation Includes an Higress port. 2s 

8. A method for configuring for distributed multicast 
fonwarding a bridge of the kind having a pluraBty of 
network interfaces sharing a backplane, each net- 
work interface having a plurality of physical ports, so 
the method comprising: 

transmitting a multicast control packet on the 
backplane; 

reviewing identifiers in the multicast control 35 
packet, the identifiers including a multicast 
group and an ingress port; and 
adding the ingress port as member port for the 
multicast group at a network interface having a 
physical port corresponding to the ingress port. 40 

9. The method according to ciann 8, wherein the 
reviewing step is conducted at a management inter- 
face on the backplane. 

45 

10. A method for configuring for distributed multicast 
fonwarding a bridge of the kind having a plurality of 
network interfoces sharing a backplane, each net- 
work Interbce having a plurality of physical ports, 
the method comprising: so 

transmitting a multicast control padtet on the 
backplane; 

reviewing identifrers in the multicast control 
packet, the identifiers including a multicast s$ 
group and an Ingress port; and 
removing the ingress port as member port for 
the multicast group at a network interface hav^ 
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Ing a physical port conesponding to the ingress 
port. 

11. The method according to daim 10, wherein the 
reviewing step is conducted at a management inter- 
face on the backplane. 

12. A method for configuring for distributed multicast 
fonvarding a bridge of fiie kind having a plurality of 
network interfaces sharing a backplane, each net- 
work interface having a plurality of piiyslcal ports, 
the method comprising: 

reoeiwng a multicast control packet for a multi- 
cast group on an ingress port; 
transmitting the multicast control packet on the 
t>ackplane; and 

adding the Ingress port as member port for the 
multicast group at a network interface having a 
physical port corresponding to the Ingress port. 

13. A method for configuring for distributed multicast 
fonvarding a bridge of the kind having a plurality of 
network Interfaces sharing a backplane, each net- 
work Interlace having a plurality of physical ports, 
the method comprising: 

receiving a multicast control packet for a muith 
cast group on an Ingress port; 
transmitting the multicast control packet on the 
backplane; and ' 

removing the ingress port as member port for 
the multicast group at a network Interface hav- 
ing a physical port conesponding to the ingress 
port. 

14. A method for configuring for distributed multicast 
foro^arding a bridge of the kind having a plurality of 
network interfaces and a management interface 
sharing a backplane, each network interface having 
a plurality of physical ports, the method comprising: 

assigning a network interface as the sole 
responsible interface for a multicast group; 
receiving a multicast control packet for the mul- 
ticast group on an ingress port; 
transmitting the multteast control packet on the 
backplane; 

retransmitting the multicast control packet on 
the backplane only from the responsible inter- 
face; and 

capturing the multicast control packet at the 
management Interface and adding the ingress 
port as member port for the multicast group. 

15. The method according to daim 14, further compris- 
ing: transmitting a fonvanling update to a network 
Interface having a physical port corresponding to 
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the ingress port, the forwarding update causing the 
networlc interface to add the Ingress port as a mero' 
ber port for the multicast group. 

1 6. The method accordii^ to claim 14, liirther compris- s 
ing: transnrHtting a foiwarding update to a network 
interface having a physical port correspondkig to 
the mgress port, the fonvarding update causing the 
network interface to remove the ingress port as a 
memt)er port for the multicast group. ro 
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